[FEATURE]

In raising this pull request, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

My familiarity with the project is as follows (check one):

• I have never used the project.
• I have used the project briefly.
• I have used the project extensively, but have not contributed previously.
• I am an active contributor to the project.

Overview

Third PR of the CI API stack (#1130 → #1141, merge bottom-up). The core read/write surface for CI runs: monitoring endpoints, run listing and detail, and the ability to trigger and cancel runs via the API.

Endpoints

System

• GET /system/health — unauthenticated, for monitors and load balancers. Reports overall ok/degraded/down plus per-dependency status (database, local storage, GCS). 503 only when down.
• GET /system/queue — queued and running work with queue_depth/running_count meta and ?platform/?status filters. Queue position is only populated under ?status=queued, where it's well-defined.

Runs

• GET /runs — filterable by status, platform, branch, repository, and creation date range
• POST /runs — trigger a run for a commit (runs:write)
• GET /runs/{id}, POST /runs/{id}/cancel, GET /runs/{id}/summary, GET /runs/{id}/config, GET /runs/{id}/progress

Implementation notes for reviewers

• ?status=queued composes with date filters. Queued runs have no progress rows yet, so the date subquery LEFT JOINs progress and treats "no first-progress timestamp" as matching. An inner join here would make ?status=queued&created_after=... silently return nothing.
• POST /runs permission model: the requesting user's GitHub identity must match the target repository (fork owner, or the main repo for maintainers — compared case-insensitively, since GitHub owner names are). The OAuth callback in mod_auth now records github_login to support this; this PR is its first consumer. Run creation also verifies a CI build artifact exists for the commit before enqueueing, so the API can't create runs that would instantly fail.
• Summary/config count only active regression tests, and customized runs count their selected subset — matching what the worker will actually execute, not the whole catalog.
• Error semantics: a completed run with zero TestResult rows is reported as error (worker finished without reporting), never pass.
• All timestamps are UTC with the same Z-suffixed format used across every endpoint in the stack.
• error_service (structured error derivation, used by run summaries here and expanded in [Feature] : API ENDPOINTS PR 6 : Errors, Logs, and OpenAPI Documentation #1135) and storage (GCS signed-URL resolution with local-file fallback) services land here with their consumers.

The auth middleware integration tests also land in this PR — they need a stable protected endpoint to probe, and GET /system/queue is it (401 paths: missing/malformed header, bad prefix, wrong hash, revoked, expired; 403 scope paths; prefix-collision resolution; g.api_user population).

Testing

61 new tests; 126 total at this layer. Query composition (status × date), permission rejections, cancellation flow, summary/config counting, health degradation paths, and the full middleware-auth matrix.